Software is often developed with many different resources (e.g., strings and/or images) to support localization, i.e., language and/or regional preferences. Example regional preferences, or locales, for a language may be the United States, Great Britain, Australian, and Canadian versions of the English language. Presently, for each software program, a separate binary is built for each different set of localized preferences. Thus, a software developer ships a binary for each and every language and perhaps separate binaries for different regional preferences for a particular language. If separate regional preferences are not supported, the resources may be fixed for a single language and thus may not reflect regional differences.
Tying the localized resources to a particular binary can create other problems. If two binaries utilize the same resource, each must carry the same resource as part of that binary, causing code bloat. In addition, the localized resources listed with a binary may become stale and cannot be updated unless the entire binary is updated. Finally, it may be difficult for a developer to access the correct binary or resources even if the above problems were removed.